Subject: More HPR Questions

From: [email-masked] (Matthew Finlayson)
Date: Wed, 10 Aug 94 18:41:00 BST

A few more questions and comments about the HPR specification.

- The Status segment contains an ASEQ field to enable a windowing protocol
  to be carried out between RTP endpoints.  Presumably this protocol is not
  used by HPR (since it is explicitly turned off in the description of the
  Connection Setup segment.  The spec should have a comment to this effect
  in the description of the ASEQ field.

- The description of the ARB Segment (A1.6.6) talks about FIELD1 for the
  RQ/REPLY message type being measured in KBits/sec rather than Milliseconds.

- the descriptions of the control vectors in sections A.1.7.1, A.1.7.2,
  A.1.7.4, A.1.7.5, A.1.7.6 state that the length contains any padding
  necessary to force embedded control vectors to start on 4-byte boundary.
  Since these control vectors can contain no embedded control vectors
  this should be removed.

- Neither the HPR specification nor the RTP specification discuss what
  should be done if the BSN wraps.  I am assuming that I should treat it
  similarly to the situation when SYNC wraps.

- The Forward Route Information CV is passed back on a negative Route
  Setup reply - is this necessary?

- Could you confirm that the Limited Resource liveness timer (carried on the
  Route Setup GDS) should be set to zero if the route contains no
  limited resource links?

- How should the SHORT_REQ timer be initialized?  The endpoint which brings
  the connection up can, perhaps, rely on the accumlated transmission time to
  give it an estimate.  The listening endpoint doesn't receive this
  information

- Can you clarify connection termination in the error case (if an
  DISCONNECT(strongly or not strongly) is issued without COB exchange).  As
  far as I understand, if the DISCONNECT is not strongly, then the issuing
  side starts its dally timer but does not send any notification to its
  partner unless it receives a packet.  In this case it replies with a
  STATUS packet with the closed bit (and also the last message bit?) set.

  Is this correct?

- What is the use of the RASAP indicator in HPR?  I'd originally thought that
  it should be used to decided whether to piggy-back the STATUS message, or
  to reply immediately with a dedicated packet, but the discussion in
  7.2.4.1.4 seems to quosh this theory - it suggests that the STATUS message
  should always be piggy-backed if there is data waiting to send.

- Are you planning on including an FSM specifying the way that RTP Status
  negotiation works in the Approved Pages Draft?  I found this to be one of
  the hardest areas to work out in the current specifications, and
  probably one of the most likely areas for interoperability problems.

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================